昨天談 Prompt Engineering I，我們用 CO-STAR 把背景、目標、風格、語氣、受眾與輸出格式拆開，試著把腦中的需求交代得更清楚。
理論上，Prompt 寫得越完整，AI 就越容易知道我們要什麼。
然後現實通常會很有禮貌地走過來告訴你：
不一定。
即使一開始已經和 AI 聊了好幾輪，把需求收斂成一個看起來非常完整的 Prompt，真正執行後，成果還是可能和腦中的畫面有一段距離。
這不是例外，而是使用生成式 AI 很常見的狀態。
原因很簡單：我們用自然語言描述的是「想要什麼」，模型則根據它讀到的文字、訓練資料與目前系統設定，產生一個它認為合理的結果。
這兩個「合理」不一定是同一個合理。
所以今天想談的不是怎麼再多背一套 Prompt 框架，而是一個更實際的能力：
觀察結果、找出落差、修改 Prompt，再試一次。
好的 Prompt 很少是第一次寫出來的。
它比較像是改出來的。
最初這個想法，是我在 2026 年 NVIDIA 活動時聽到林思翰導演用一連串影片分享整個流程；事後我自己也做了一個類似的影片來實驗。
如果可以請你也打開影片，我們一起來觀察：
一個人漫步在校園裡，後來出現一隻怪物。
這是一個簡單的 Prompt。看到它，每個人心中都會出現自己的畫面；對我來說，大概就是懸疑、恐怖的氛圍感。
然後把需求交給生成式 AI 之後，就會發現模型對「一個人走在校園，出現怪物」這句話有自己非常獨特的見解（OS：我到底看了什麼……）。
當出現不如預期的結果時，先別怪 AI；畢竟它的 IQ 絕對比我還要高。更實際的是，它不會自動知道我腦中的鏡頭語言。我們要回頭看看：是不是還沒把需要的視角描述清楚？
用第一人稱視角，一個人漫步在校園裡，後來出現一隻怪物。
第二版的視角對了，感覺也來了！但最後面還是歪樓了……我都懷疑這個 AI 的預訓練是否有包含含淚跳恰恰，整個畫風到後面我都想跳起來了。
是的，我們大概又沒跟 AI 說清楚要什麼樣的感覺，畢竟懸疑、恐怖、驚悚的氛圍都是腦補出來的。
用第一人稱視角，一個人漫步在校園裡，突然出現一隻怪物，要有驚悚的感覺！
這版的感覺來了！但畫面莫名停留在一個奇妙的拐點，怪物出現不是要嚇人嗎？這個停格跟獵人斷更一樣殘忍。音樂有了驚悚的氛圍，畫面卻好像還沒有。
用第一人稱視角，一個人漫步在校園裡，突然出現一隻怪物，音樂和畫面要有驚悚的感覺！
最後這個感覺逐漸趨近於一開始心中所想的畫面了吧！把過程拆開，大概就是：
需求
↓
第一版 Prompt
↓
AI 輸出
↓
觀察結果
↓
找出與預期的落差
↓
修改 Prompt
↓
重新執行
↓
再次比較
如果還是不對，就再改一次。
整個流程說起來並不難，但真正困難的是：
你看不看得出來哪裡需要改？
這也是為什麼，我覺得 Prompt Engineering 的核心能力，不只是「會寫 Prompt」。
更重要的是：
會驗收。
這也是我在學習 AI 過程中，越來越有感的一件事。模型能力越強，人的能力並沒有變得不重要，只是人的工作開始往上移。以前可能要自己畫圖、自己寫程式、自己做簡報。
現在 AI 可以協助完成很多執行工作，但人開始需要負責：
如果是專業領域，這件事更加明顯。
例如請 AI 判讀一張地質圖、分析統計結果，或整理一篇醫學研究。模型可以產生非常流暢的回答。但如果使用者缺乏領域知識，就可能連哪裡不合理都看不出來。
這也是為什麼「AI 會做」不代表「人可以完全不用懂」。
有些工作確實可以降低技術門檻。
但驗收門檻不一定跟著消失。
甚至有些時候，因為 AI 做得太像真的，驗收反而變得更重要。
假設我請 AI：
幫我把這張簡報做得更好。
AI 回傳了一張字比較大、顏色比較漂亮、圖片也換掉的簡報。到底有沒有變好？
不知道。
因為「好」沒有被定義。
所以當 AI 產生的東西超過你個人能力時，或許就是開始延伸學習其他領域的時候：什麼叫好的投影片？什麼是好的程式？唯有跟著 AI 一同成長，才有機會慢慢駕馭它的產出。所以「人機互動」的過程，更像是「人機一起成長」的過程。
如果連自己都不知道要什麼，AI 就會用一堆腦補來產生東西；使用者若一路替它開綠燈，最後反而可能被它的答案牽著走，人只是被AI吊起來的操線木偶。
Prompt 在迭代的過程中，其實很適合同步訓練 AI 時代下的流程思維。人在成長過程累積了大量經驗，有時不需要把一件事說清楚，別人就知道怎麼操作。
例如影片中所說的「做一片果醬吐司」。
但跟 AI 對話，就需要把流程拆得更細一點。用寫程式的思維與 AI 對話，往往容易得到較好的結果。同樣地，很多人不知道如何導入 AI；如果去看外部建議，常會看到從高頻率、高重複、低決策風險的工作開始。
下一個問題是：我哪知道這個要從哪邊找？
你可以想一下最近那個想遞出辭職單的時刻，可能是一個專案，也可能是一項任務。藉由跟 AI 不斷對話來拆解流程，進而找出可以導入的點。
上述 Prompt 迭代比較適合對話、圖像生成、影片生成等任務；如果是相對複雜的任務，後面牽扯到一堆工具，就很難量化出 Prompt 的作用。
到了真正的 Agent 系統，外面可能還會繼續加上（僅列出小部分）：
模型開始像一顆引擎，外面逐漸接上方向盤、煞車、儀表板、導航、車架與安全帶。
這些包在模型外面、協助模型取得資訊、呼叫工具、維持狀態、執行規則與完成任務的系統，可以先用一個現在越來越常看到的詞來理解：
Harness
Anthropic 在介紹 Agent 評估時，把 Agent Harness（或 Scaffold） 定義成讓模型能夠以 Agent 方式運作的系統：它處理輸入、協調工具呼叫，再把結果返回。
OpenAI 在新版 Agents SDK 中，也使用 model-native harness 這個概念；它可整合 instructions、tools、memory、sandbox 與執行流程，讓 Agent 能跨檔案與工具工作。
因此，對剛開始學習的人，我們可以先用一個非常簡化的模型：
Agent ≈ Model + Harness
但要注意，這是一個理解用的類比，不是所有研究與框架都共同採用的數學公式。
Model 是核心語言模型。
Harness 則是圍繞模型、讓它更穩定完成工作的執行框架。
例如 Day 6 談到的 Function Calling，本身就是 Agent Harness 中很典型的一部分：模型可以提出要使用哪個工具與所需參數，Harness 則依權限與規則驗證、執行，再把結果接回真正的程式流程。
所以當一個 Agent 表現不好時，問題不一定全部出在模型。
可能是：
如果把所有問題都歸因成：
換一顆更大的模型看看。
有點像車子方向盤鬆掉，處理方式卻是換一顆更大的引擎。馬力增加了。方向盤還是鬆的。
Prompt 很重要。
但 Prompt 只是整個系統中的其中一層。
這不是說 Prompt 沒用。當任務目標、輸出格式、風格或限制還不清楚時，Prompt 仍是最直接的工作說明。
只是模型與工具能力會進步，某些原本必須逐條寫死的規則，之後可能變成多餘限制。與其把規範檔越疊越厚，不如把每條規則當成一個假設：先拿掉、照常使用；只有在模型反覆踩到同一個坑時，再把它加回來。
數位時代整理 Claude Code 負責人 Boris Cherny 的實務經驗時，也提到類似做法：隨著模型能力提升，Claude Code 團隊曾大幅縮減系統提示，並以刪除、使用、再視重複失敗補回規則的方式檢查提示是否仍有價值。這是特定模型與產品的實務經驗，不代表每個 AI 系統都該照做。
因此，Prompt 迭代的目標不是讓指令越長越好，而是找出什麼會真正改善成果。面對創作任務，驗收的是鏡頭、節奏與氛圍；面對程式任務，驗收的是測試、畫面與實際行為；面對會改變外部世界的工具，則要確認動作是否真的完成。
Anthropic 在談 Context Engineering 時，也指出 Agent 的行為不只受到 Prompt 影響，還包含工具、MCP、外部資料、訊息歷史，以及整個 Context 的管理方式(這個我們後續會說明)。
到了更複雜的系統，真正需要調整的可能是下列幾層(不是每個 Agent 都必須全部具備)：
Prompt
+ Context
+ Tools
+ Memory
+ Workflow
+ Guardrails
+ Evaluation
+ Model
而不是每天坐在電腦前研究：
「請」改成「務必」會不會讓準確率多 3%？
Prompt Engineering 是很好的入口。
因為它讓我們第一次開始思考：人要如何把意圖交給模型？
但之後會逐漸看到，更大的問題其實是：
整個系統要如何提供模型足夠、正確，而且不過量的資訊，讓它完成工作？
這也是我們之後會走到 Context Engineering、MCP、Skill 與 Agent 架構的原因。
回頭看那支影片，一開始只是：
一個人在校園漫步，後來出現怪物。
經過一次又一次生成後，我們逐漸補上：
表面上，是 Prompt 越寫越完整。
但另一個角度看，是我們透過 AI 的輸出，逐漸看清楚自己真正想要的是什麼。
所以 Prompt 迭代不只是：
AI 沒做好，所以我再叫它一次。
而比較像：
我觀察它做了什麼，找出和目標的差距，再把自己的需求說得更清楚。
這又回到了 Day 1 提到的節奏：
觀察 → 反思 → 迭代。
AI 的確可以幫我們加速很多工作。
但真正讓成果逐漸變好的，往往不是某一句傳說中的神 Prompt，而是使用者有沒有能力看見差距。
明天，當你已經知道怎麼透過 Prompt 引導模型，也知道 Agent 能調用工具時，可能會覺得可以開始顛覆這世界了！但先等等，或許我們要先了解一下安全議題。
iThome鐵人賽
看影片追技術